A Customer Information Control System (CICS) is often used to manage large-scale computer processing transactions for “enterprise” user organizations such as banks, brokerage firms, insurance companies, large retailers, etc. To ensure the continuous availability of such systems in meeting business processing needs as well as to meet Service-Level Agreement (SLA) targets, such users have embraced the “parallel sysplex” data sharing model and the GDPS (“geographically dispersed parallel sysplex”) for designing a computer operating system (such as the IBM z/OS®) to implement a CICS solution, which uses “multiple virtual storage” (MVS) operating systems divided into “logical partitions” (LPARs) that communicate for simultaneously storing and/or processing the data and program instructions needed to carry out CICS functions in managing workload distribution for an environment involving multitasked parallel computer processing resources.
With the advent of internet/web-based transaction processing, more enterprise users are moving towards implementation of a “service oriented architecture” (SOA) that utilizes a CICS system as the “back-end office” database server for the enterprise. As a result, the increasing number and volume of processing requests from web-based service requestors/messaging systems has resulted in a significant increase in CICS server transactions, causing system performance degradation due to “workload surging” during distribution (or “routing”) of high volume processing task(s) requiring sub-second response times.
Existing CICSplex system workload management (WLM) algorithms (such as those disclosed in U.S. Pat. Nos. 5,504,894 and 5,475,813 which are incorporated by reference as if fully set forth herein) require “target” hardware/software resources (delineated into LPAR “regions” used in carrying out assigned processing tasks) to update current workload completion status/processing capacity (or “health”) every fifteen (15) seconds to a local system address space manager (CMAS). However, the delay involved in transmission of this processing health information to “routing” hardware/software resources (also delineated into LPAR regions for distributing assigned processing tasks to target regions) results in inaccurate views of the “point-in-time” (i.e., “real-time”) processing capacity of available targets when multiple LPARs or MVS address spaces are operating as cloned “images” of each other in managing a CICS workload (where the images may reside in the same “sysplex” or in multiple “sysplexes”).
In a very high volume workload environment often involving the routing of over three-thousand (i.e., 3000+) processing transactions per second, the routers cannot maintain an accurate “real-time” accounting of the health of all target processing regions utilized for all LPARs, which results in an observed “surging” of transactions to a specific target region every fifteen seconds. This “surging effect” results in degraded processing performance as a target becomes saturated with work requests (and as a result may experience a “maxtask” and/or “stall” condition due to loss of storage space) until it can report its current (updated) processing health at the next fifteen second interval.
Other solutions to this problem have been suggested (such as shortening the fifteen second “heartbeat” interval for reporting target health) but this would increase central processing unit (CPU) usage time consumption in the target regions (and also result in increased use of virtual memory storage dataspace in distributing this information to other LPAR regions). The concept of using “coupling facility” structures in a “parallel sysplex” data sharing environment (to hold workload management health information) has also been explored, but that solution would only apply to a single “sysplex” environment and therefore would require redesign of many current CICSplex systems (while also introducing significant “coupling facility lock structure overhead” to a processing environment which is already prone to performance degradation).